Two blackhole-resume double-apply shapes, and a ratio gate that fails on a non-measurement - #1095

…loor

A clamped pypy baseline no longer gates anything. #1095 made
`_baseline_exec_time_clamped` return before both the ceiling and the derived
floor, so a fixture whose pypy side sits on EXEC_TIME_FLOOR_S is ungated on
the ratio entirely -- lifting it above the floor is now the only way such a
fixture has a perf gate at all.

The trip counts are solved, not guessed. Timing pypy at 1x, 8x and 32x of each
committed knob gives a per-iteration slope; the new knob is the count that puts
pypy at FLOOR_GATE_MIN_BASELINE_S, rounded up to two significant digits. Of the
270 clamped fixtures, 143 keep their trip count as an inline literal rather
than a module-level knob and are left alone -- a `range(300)` is often a
recursion depth or a threshold, and rewriting it silently changes what the
fixture covers -- 7 are flat under pypy at any size, and 91 respond. 20 of
those reach the floor within 64x while keeping pyre's projected execution well
under the 20s bench timeout, which is the bound that excluded
`closure_per_call` (23.2s), `inline_gate_operand_provenance`, `binary_slice_index`
and `class_reassign_hot`.

Three more were scaled and then reverted, because scaling them bought CI time
and no gate: `exc_info_module_loop_hot` and `exec_defined_global_read` still
read clamped afterwards, and `enumerate_bignum_start` still records
`loops_compiled=0`, so its ratio would compare two interpreters rather than any
generated code.

Five ceilings move as a consequence, in both directions, because an unclamped
ratio is a different quantity from the clamped one it replaces:
`bound_method_builtin_fold` 48 -> 160 and `inlined_helper_mutation` 45 -> 145
were fitted against the clamp and fail without this; `unary_negative` 110 -> 220
sat directly on its own reading; and `unary_positive_resume` 90 -> 5 collapses,
because at the old trip count the numerator was mostly pyre's fixed warmup,
which the longer loop amortises. `loop_callee_shared_mutation` predates the
convention and had no ceiling at all; it compiles two loops and now gets one.

Measured cost: +273s per check.py run, about 14 minutes across the three
runners.

Assisted-by: Claude

…ngs to measured ratios (#1086)

* bench: widen two blanket ceilings the macos runner crosses

`object_getattribute_no_hook` reads 6.8x on the macos runner and up to 7.8x
here against a ceiling of 5; `operator_error_typename` reads 11.0x there
against 10. Both ceilings are blanket values from the sweep that first gave
every synthetic fixture a `max-pypy-ratio`, never fitted to a measurement.
Each is now twice the slowest ratio observed, and pypy's denominator is
clamped for both, so neither ratio is a measurement to begin with.

Assisted-by: Claude

* bench: refit nine ceilings to the ratios the runners actually report

The linux runner fails `exception_const_operand_resume` at 23.9x against a
ceiling of 20, `getframe_force_cancel_journal` at 30.8x against 29, and
`unpack_drain_star_raise` at 52.7x against 49.

The other six sit within 2% of the bound the gate really applies (the ceiling
plus `compare_buffer / exec_baseline`) in runs already recorded, so they fail
on the next scheduling accident rather than on a change: `class_attrs_methods`
15.7x/15, `exception_dict_slot_reject` 5.8x/5, `defaults_reassigned_midloop`
17.8x/17, `store_slice_hot` 15.8x/15, `exception_reduce` 32.5x/32,
`comprehension_object_append_hot` 51.0x/41.

Each ceiling is now twice the slowest ratio observed across the three runners
and this machine, with that observation stated in the header.

Assisted-by: Claude

* check.py: raise the pypy floor divisor to clear a fixture's own host span

The divisor has to clear that span twice over: a ceiling sits at twice the
slowest runner's ratio, and the floor derived from it still has to land under
the fastest runner's. `defaults_reassigned_midloop` reads 1.0x and 17.8x
across the runners, `foriter_inplace_immutable` 1.0x and 16.9x,
`class_attrs_methods` 1.0x and 15.7x, so at 25 each of their honest ceilings
put the derived floor at exactly the ratio their fastest runner reports.

At 40 no observation in the runner logs sits under its floor, and the count
within 25% of one drops from 61 to 27. Raising the divisor only lowers floors,
so nothing that passed can newly fail.

Assisted-by: Claude

* bench: refit the four macos ceilings and drop the ratio gate from a loopless fixture

The macos runner failed five synthetic ratio gates. Four are refitted to twice
the slowest ratio the runners report, with the observation stated in the
header: exception_catching_frame_tb_node 18 -> 53 (26.2x),
global_cell_shortpreamble_hot 19 -> 46 (22.7x),
inline_subwalk_mutating_residual 40 -> 102 (50.9x), float_builtin_hot 8 -> 27
(13.5x, read against a floor-clamped pypy baseline, so a lower bound).

getattr_attribute_fallbacks loses its `max-pypy-ratio` line instead. The
fixture has no loop and records loops_compiled=0 on dynasm, cranelift and
wasm, so its ratio compares interpreter startup rather than compiled code; it
reads between 1.0x and 12.2x across the runners without the fixture changing.
42 synth fixtures already carry no ratio header, and its jitstats baselines
still gate it.

Assisted-by: Claude

* bench: refit fifteen ceilings that sit inside the run-to-run spread

Ranking every synth fixture by the worst ratio the runners report against the
gate's effective bound (limit + compare_buffer/exec_baseline, which on posix
with a clamped baseline is limit + 1) leaves fifteen whose worst reading is
under 1.0 of that bound -- close enough that one noisy run reds them. Each is
refitted to twice its worst posix reading, with the observation in the header.

The bound is computed per platform rather than from the printed ratio: windows
adds 2*(1/64)*(1 + limit) to the compare buffer, so a short bench there is not
meaningfully ratio-gated and its readings are not a basis for a ceiling.

Assisted-by: Claude

* bench: drop the pypy ratio gate from the 69 fixtures that compile no loop

Each of these records `loops_compiled=0` in its jitstats, so the ratio the gate
reads is the difference between two interpreters' process startup, not the cost
of anything generated. None of the 69 has a pypy baseline above 0.05s on any
posix runner -- 68 of them median at or below it, startup included -- so after
startup subtraction the denominator is the execution floor and the quotient is
whatever that run's spawn cost happened to be.

Measured on one fixture of this shape, the reading moved between 1.0x and 12.2x
across runners with nothing about the fixture changing.

Their jitstats baselines still gate them.

Assisted-by: Claude

* bench: scale three fixtures whose loop was too short to compile, rather than ungate them

`loops_compiled=0` has two causes and the previous commit treated them as one.
A fixture with no loop cannot be ratio-gated at any size. A fixture whose loop
is simply shorter than the JIT threshold is a bench that needs a bigger trip
count, and dropping its gate hides that.

Scaled to the smallest size at which the loop compiles and pyre's own execution
is an order of magnitude above a scheduler tick:

  condexpr_heap_const_merge  N      1000 -> 64000  loops_compiled 0 -> 2
  surrogate_class_kwargs     REPEAT  100 -> 3200   loops_compiled 0 -> 3
  surrogate_dir              REPEAT  100 -> 1600   loops_compiled 0 -> 1

Their ratio gates are restored at four times the slowest ratio check.py
observes, and the jitstats baselines are re-recorded on all three backends.
The other four fixtures with a scalable trip count still record
`loops_compiled=0` at 64 times their size, so their gates stay dropped.

Assisted-by: Claude

* bench: record the six jitstats counters this branch added

`--snapshot` writes fbw_blackhole_adopted_multi_frame,
fbw_blackhole_adopted_single_frame, fbw_rolled_back_with_effects,
fbw_store_journal_rollback_failed, field_pos_attached_misplaced and
field_pos_spec_misplaced into every fixture baseline. All read zero, and no
counter that already had a value changes.

Assisted-by: Claude

* bench: scale the 26 fixtures whose pypy execution responds to the trip count

Measured pypy execution net of an empty-script baseline at both sizes: these 26
cross 50ms, the value `_performance_gate_passed` requires of a baseline before
it arms the derived floor. Fixtures whose pypy denominator clears that
threshold go from 4 to 30 of 373.

A wider calibration covering 135 fixtures was measured and discarded. For the
other 109, pypy's execution does not respond to the trip count at all -- at 64x
the workload `import_name` reads 4.4ms then 2.2ms and
`defaults_reassigned_midloop` 3.2ms then 2.8ms, several below the empty-script
baseline -- so raising their counts multiplied the numerator against a pinned
denominator, turned 36 fixtures red without making any ratio a measurement, and
cost 160s of wall clock across the three backends.

Four ceilings are refitted against the denominators that are now real. Three
read higher: a baseline pinned to the floor over-estimates the work pypy did,
so every ratio measured against it was a lower bound. import_math drops from
291 to 8 -- that bound was never fitted to an observation, and any ceiling at
or above PERF_GATE_FLOOR_DIVISOR pins the derived floor to parity, which a
fixture running within 1.3x of pypy cannot hold on a host where pyre lands
faster.

Assisted-by: Claude

* bench: declare the cpython opt-out on the three fixtures that were timing out

Sizing these three so pypy's execution is a measurement also put them past
`SYNTHETIC_CPYTHON_REFERENCE_TIMEOUT_S`. The cpython reference was being
dropped by timeout rather than by declaration: the cpython/pypy output
cross-check disappeared with nothing in the fixture saying so, and every run
spent the full 5s to arrive at that drop.

The two requirements do not both fit. A count small enough for cpython to
finish leaves pypy an order of magnitude under the startup-subtraction floor,
which is the condition `# pyre-check: skip-cpython` exists to declare.

Assisted-by: Claude

* bench: widen the nested_break_not_hot ceiling past its own clamp swing

pypy's execution for this fixture sits on the startup-subtraction floor and
crosses it between runs. With pyre's time identical at 0.11s on one host,
back-to-back runs read 6.4x/8.4x and 11.9x/22.2x across the native backends,
the whole swing coming from which side of the floor pypy landed on. The 17 it
carried sits inside that swing.

Raising the trip count is not available here: measured at 64x the workload,
this fixture's pypy time does not respond to it.

Assisted-by: Claude

* bench: re-record the exceptions jitstats after the rebase

`guard_failures` drops 202 -> 201 on all three backends under the JIT work this
branch was rebased onto. The baseline it replaces was recorded before that base.

Assisted-by: Claude

* builtins: normalize a range bound without the BigInt round-trip

`range_index_bound` converted every bound to a `BigInt` and back. The
round-trip normalizes -- `space_index` returns an int-or-long argument
unchanged and pyre's int/long are leaf types, so a `bool` would otherwise
survive as a `bool` and `range(True).stop` would expose `True` -- but only
the `bool` case needs a new object. A plain int is already the wrapping the
round-trip produced, and a long that fits a machine word is rewrapped through
`range_obj_as_i64`, which is the narrowing `iter()` reads when it picks
`rangeiterator` over `longrange_iterator`. The `BigInt` path stays for a
long that does not fit.

The three-argument step test spelled `range_obj_to_bigint(w_step) ==
BigInt::from(0)`, allocating two `BigInt`s per call; it now reads the machine
int and compares to 0, keeping the `BigInt` comparison for a step too wide
for a word. `functional.py W_Range.descr_new` spells this `space.int_w`.

Behavior is unchanged: bool, plain int, fitting long, wide long, an
`__index__` object, a negative step, a wide step, and a bad type all produce
the same values, types, and exceptions as before.

Measured by interleaving the two binaries under load, min of 9 runs each at
2M iterations: `len(range(4))` -16.8ns/iter, `len(range(n))` -31.5ns,
`len(range(0, 10, 2))` -19.0ns, `len(range(True))` -43.9ns,
`len(range(Index(4)))` -91.8ns, against +1.5ns for the empty-loop control.
This is below what `range_ctor_in_loop` can show -- that fixture costs
~14650ns/iter, so the change is diluted about a hundredfold there.

Assisted-by: Claude

* bench: re-record the wasm guard_failures the range bound change moves

`closure_per_call` reads guard_failures 418 where the baseline holds 420. The
fixture calls `range()`, and dropping the BigInt round-trip from the bound
normalization removes allocations the guest counts: `PYRE_GC_INTERP` is on
under wasm, so `w_int_new` is collector-allocated and enters
`threshold_reached`, where natively it takes an untracked
`alloc_with_gc_header`. Crossing that threshold arms the eval-breaker word
that every compiled back edge polls through a real guard, so fewer crossings
are fewer counted failures. `check.py`'s note on the two GC pins already
names this sensitivity -- interpreter-path allocation volume moves the wasm
numbers while the native ones sit still -- and the native baselines are
indeed unchanged.

Attributed by a control arm rather than by the argument above: with
`builtins.rs` reverted to its pre-change version and everything else on this
branch held fixed, the fixture passes against the recorded 420.

Assisted-by: Claude

* bench: restore the wasm guard_failures reading check.py documents

#999 re-recorded this fixture's wasm baseline from 638 to 637. The guest reads
638 here, and 638 is also the value `check.py`'s own note on the two GC pins
states the guest produces -- "the guest ... reads
`recursive_call_frame_relocation` 638 and `closure_per_call` 420 against their
636 and 414" -- a comment #999 left unchanged while moving the number it
describes.

The branch is not the source: the same fixture passed against 638 on the
previous base with this branch's `range()` change already applied, and the
mechanism that moves this counter is old-gen allocation volume, which that
change lowers rather than raises.

Assisted-by: Claude

* bench: scale twenty fixtures until pypy's execution clears the gate floor

A clamped pypy baseline no longer gates anything. #1095 made
`_baseline_exec_time_clamped` return before both the ceiling and the derived
floor, so a fixture whose pypy side sits on EXEC_TIME_FLOOR_S is ungated on
the ratio entirely -- lifting it above the floor is now the only way such a
fixture has a perf gate at all.

The trip counts are solved, not guessed. Timing pypy at 1x, 8x and 32x of each
committed knob gives a per-iteration slope; the new knob is the count that puts
pypy at FLOOR_GATE_MIN_BASELINE_S, rounded up to two significant digits. Of the
270 clamped fixtures, 143 keep their trip count as an inline literal rather
than a module-level knob and are left alone -- a `range(300)` is often a
recursion depth or a threshold, and rewriting it silently changes what the
fixture covers -- 7 are flat under pypy at any size, and 91 respond. 20 of
those reach the floor within 64x while keeping pyre's projected execution well
under the 20s bench timeout, which is the bound that excluded
`closure_per_call` (23.2s), `inline_gate_operand_provenance`, `binary_slice_index`
and `class_reassign_hot`.

Three more were scaled and then reverted, because scaling them bought CI time
and no gate: `exc_info_module_loop_hot` and `exec_defined_global_read` still
read clamped afterwards, and `enumerate_bignum_start` still records
`loops_compiled=0`, so its ratio would compare two interpreters rather than any
generated code.

Five ceilings move as a consequence, in both directions, because an unclamped
ratio is a different quantity from the clamped one it replaces:
`bound_method_builtin_fold` 48 -> 160 and `inlined_helper_mutation` 45 -> 145
were fitted against the clamp and fail without this; `unary_negative` 110 -> 220
sat directly on its own reading; and `unary_positive_resume` 90 -> 5 collapses,
because at the old trip count the numerator was mostly pyre's fixed warmup,
which the longer loop amortises. `loop_callee_shared_mutation` predates the
convention and had no ceiling at all; it compiles two loops and now gets one.

Measured cost: +273s per check.py run, about 14 minutes across the three
runners.

Assisted-by: Claude

* bench: record the pypy_type_surface counters main's own CI reports

The fixture arrived with #999 recording bridges_compiled=5 and
guard_failures=1011, and the JIT changes that landed after it moved both
without a re-record. It reads bridges_compiled=102 and guard_failures=20497
here on all three backends, with loops_compiled=11 unchanged.

Not this branch's: `pypy_type_surface` contains no `range()` for its only
interpreter change to reach, and main's own `pyre CI` run at this base fails on
exactly these three lines from ubuntu-24.04 -- `bridges_compiled 5 -> 102,
guard_failures 1011 -> 20497 (observed loops_compiled=11 bridges_compiled=102)`
-- so the recorded value reproduces on neither platform. Re-recording it agrees
with both.

Assisted-by: Claude

* bench: refit the sixth ceiling the unclamped ratio invalidates

`list_append_funcentry_helper` reads 61.9x on cranelift against its ceiling of
61 once its pypy baseline clears the startup-subtraction floor. Same cause as
the five refitted alongside the trip counts: the ceiling was fitted while the
baseline was pinned to the floor, which over-states pypy's work and so
under-states the ratio built on it. Twice the slowest backend observed.

Assisted-by: Claude